(Insert Diagram Here)

• Schema can be used to precreate emf model, or simply to validate it as getEClass is called and during the setup of the getEObject.

• How does reverse direction work? Model changes, text is updated, need mapping that includes whitespace. One option is xslt, but how does that work for generic parsers? The XML input would need to be generic, and it needs access to old file. If parser includes whitespace in some version of the model. That model could be written out with a generic preg. White space could be stored as annotations to main model. Because main model is direct mappig this would also be easy to write out again. New model objects need rules/templates for white space. Templates would be needed to create each "new" object has a snippet of text which is its template.

(Another Diagram)

• Custom parsers create both whitespace model and main model. 2 models together are serialized to the text file.

• Should Eclipse document view use these two models directly instead of maintaining its own model? In GMF the view model is maintained separately. Just like the relationship between JFace viewers and the gui widgets. The actual widgets have there own model and the viewer just keeps it synced with the object model.

• How is program written to take 2 models and write out text? If model & format/whitespace model are completely generic then this can be done once. "whitespace model" need everything not in main model.

• If model element selection is maintained as a path then model can just be regenerated for each change of the text file, but that will be slow. That would be fixed if we had a custom document view model.

• Even if document view maintained text, with the annotaiton model it should be possible to do "inseritions" using the annotation model positions, note in this case these pos in the annot model should be "locations" in the doc view. That seems link the way to go. The only problem is the parser.

• Is there a way for the parser to do incremental model changes? Simple error checking can be done without needing to change the model. If the annot has location independent positions.

• Should support 2 levels of parser, incremntal and standard.
  • Standard just regenerates model for every valid change in the document.
  • Incremental updates existing models as text is changed. Standard tools can give parser context and text. From this it needs to regenerated any state it needs. Seems this might not be bad if a few parser conventions are followed.

• What about existing parsers from libConf and GST?
  • GST takes file makes xml, takes xml and file and updates. Because xml is highlevel there is not much userful here. That type of parser could be integrated in so real time editing of the file and model could be done in eclipse. Might be too slow unless ST parser can be kept in memory.
  • libConf - it can generate xml also so saome thing goes. If there is a perl java bridge then internal strucutre of parser can be used and directly converted to emf instead of file->libcof->xml->emf it would just be file->libConf->emf.

• The problem with any external parser is the annot model will not be supported. This doesn't mean full parsers can't be written in other langs, but those parsers must onform to the apis of this framework.

(another diagram)

• Perhaps similar to GMF it is not necessary to save the DocAnnot modle, just the text file is enough.
• Unlike GMF we also don't need to save the semantic model. Because the text file is the master this model can be recreated.